從去年開始，我越來越常聽到同一種焦慮：站長打開 GA4，看著這個月幾千個工作階段；接著切到主機商的流量統計或是 raw access log，赫然看見幾十萬筆請求。這中間差了一到兩個數量級。
第一反應通常是「靠，一定有哪邊壞了」。但其實兩邊都沒壞，它們只是在測量完全不同維度的現實。而且這道落差正在急速撕裂，因為過去這兩年，網路上多了一大票在前端打點工具裡「結構性隱形」的新訪客。
接下來這 30 天，我們只盯著這類訪客看：AI 爬蟲。今天先不談哪隻爬蟲是誰家的（那是明天的事），也不談它們來拿什麼（那是第三天）。今天我們只把最基本的一件事搞懂：為什麼你手上的兩份數據會互相打臉，以及你要怎麼在十分鐘內，用自己的 log 把這段落差硬挖出來。
先排除掉最蠢的誤判，免得後面的分析全盤皆輸。
所以「12 萬請求 vs 8,000 工作階段」這種比較，本來就會差上幾十倍，跟爬蟲半毛錢關係都沒有。
要做有意義的對決，log 這邊必須先收斂到「頁面請求」：只留 HTML 回應，把靜態資源全丟掉。最粗暴但堪用的做法，就是只留沒有副檔名或副檔名是 .html 的路徑，而且只算 200 成功的。
這件事先做掉，剩下的落差才是真的落差。而剩下的這些，才是今天的主角。
這是最大的一塊盲區，很多人知道原理，卻低估了它的殺傷力。
GA4 的資料收集全靠那段 Google tag（gtag.js）。官方文件第一句話就是要你把它塞進 <head> 裡。你貼的是一段 JavaScript，瀏覽器必須把它載進來、執行它，然後才會打一個請求回 Google 的端點。
也就是說，判斷一個訪客會不會出現在 GA4 裡，只取決於一個靈魂拷問：它跑不跑 JS？
一般爬蟲的答案是拒絕。Common Crawl 的 CCBot 在 FAQ 裡冷冷地交代：「Currently, JavaScript is not executed and Cookies are not used.」這不是偷懶，是因為要掃描整個網際網路，幫每個頁面都開一顆算繪引擎的成本太高了。對多數只想要「內容」的爬蟲來說，跑 JS 是一種太過親密且昂貴的承諾，它們只要純文字，拿了就走。
反面教材是 Googlebot，它會算繪 JS。Google 文件把流程拆成三階段，其中 Rendering 階段就是用 headless Chromium 把頁面渲染出來並執行 JS。
所以別再說「爬蟲一定不跑 JS」了。正確的現實是：跑 JS 很貴，所以是例外，不是常態。 而那個例外，目前主要是搜尋引擎，不是 AI。
這導致了一個很毛骨悚然的結果：一個不跑 JS 的訪客，在你的 access log 裡把時間、IP、路徑、User-Agent 留得清清楚楚；但在 GA4 裡，它連存在過的痕跡都沒有。不是被歸類到別處，是根本沒發生過。
就算真的有隻爬蟲跑了 JS、把事件打出去了，GA4 還有第二道門禁。
Google 官方說明寫得近乎冷酷（下面是原文）：
"traffic from known bots and spiders is automatically excluded"
"Known bot and spider traffic is identified using a combination of Google research and the International Spiders and Bots List, maintained by the Interactive Advertising Bureau."
"At this time, you cannot disable known bot traffic exclusion or see how much known bot traffic was excluded."
這三句話值得反覆咀嚼。第一句：自動排除，沒得商量。第二句：名單來自 Google 加上 IAB。第三句最致命：你不能關掉它，也看不到它排除了多少。
這才是真正的黑洞。GA4 就像一個過度保護的伴侶，自顧自地把可疑的訪客全擋在門外，而且連「擋了多少人」都不屑告訴你。你手上看著的數字，是經過一道你看不見、也拆不掉的濾網後剩下的殘渣。
舊的 UA 時代你還可以自己打勾決定，GA4 直接把它焊死了。對行銷人來說這很貼心，沒人想看轉換率被爬蟲搞砸；但當你想搞清楚「到底誰在讀我的網站」時，GA4 直接把答案沒收了。
前面講的都是機器人為什麼消失。這個機制解釋了為什麼連活人也會不見。
「被廣告攔截器擋掉」這句話大家都在講，但其實它把三種完全不同的失效機制混為一談。我實際把清單抓下來看過（2026-09-06），結果是它們以三種不同的方式搞砸你的數據：
第一種：把你擋在門外。 EasyPrivacy（uBlock Origin 預設清單）很狠，兩個網域都收：
||googletagmanager.com^
||google-analytics.com^$script,third-party,xmlhttprequest
連請求都發不出去，事件直接死亡。
第二種：看你用哪個門。 Firefox 追蹤保護用的 Disconnect 清單。我把它的 services.json 抓下來數，google-analytics.com 出現 3 次，但 googletagmanager.com 出現 0 次。這意味著，如果你是透過 GTM 裝 GA4，這份清單根本攔不住你。
第三種：假裝不認識你。 Safari 的智慧型防追蹤（ITP）根本不擋網路請求。它的官方定義是限制 cookie 與網站儲存資料。在 ITP 底下，GA4 事件照樣送得出去。壞掉的是「認人的記憶」。同一個人明天再來，對 GA4 來說就是個完全陌生的新歡。你的總量沒少，但「不重複訪客」和「回訪率」爛成一團。
三種機制，一種事件消失、一種看你怎麼安裝、一種假裝失憶。把它們混在一起談，你永遠估不準到底少了多少人。
至於被擋掉的比例？我刻意不寫。網路上流傳的「X% 被擋」都是別人的業障。你要的不是別人的數字，是你自己伺服器上的真相。
前面四個都是「後端有紀錄、GA4 沒紀錄」。這個坑剛好相反：兩邊都沒有。
如果你網頁前面擋了一層全頁快取（CDN、WP Rocket 等），熱門頁面的請求在快取層就被打發掉了。你的應用程式從頭到尾都在沉睡。
我親自踩過這個坑。最慘的是：漏掉的量是量不出來的。 你不能從剩下的聊天紀錄，去反推對方到底收回了什麼訊息。我曾經試圖用「首頁的爬蟲數偏低」來推算漏了多少，後來發現這根本是拿單一門市的客流量去猜全國營業額。
唯一的解法，是去調快取層（CDN）自己的 log 來對。在做這件事之前，要知道：如果你的打點裝在應用程式裡，你的 access log 早已不是完整的門口監視器了。
理論結束。下面這些是可以直接貼進終端機跑的指令，適用 Apache/nginx 的 combined log 格式。
我用一份合成的示範 log（1,684 列，權重我自己配的）來展示輸出長相。請用你自己的 log 跑，那才是你的現實。
combined 格式裡，User-Agent 是用雙引號括起來的最後一個欄位。用 " 切第 6 欄最快：
# 總列數
awk -F'"' '{print $6}' access.log | wc -l
# 帶有已知 AI/爬蟲 token 的列數
awk -F'"' '{print $6}' access.log | grep -Eic \
'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|PerplexityBot|meta-external|CCBot|Googlebot|bingbot|AhrefsBot|SemrushBot|facebookexternalhit|HeadlessChrome'
示範 log 輸出：
1684
1115
1,684 列裡，有 1,115 列帶著爬蟲的刺青。剩下 569 列才像一般的瀏覽器。
awk -F'"' '{print $6}' access.log \
| sed -E 's#.*(GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|meta-externalagent|CCBot|Googlebot|bingbot|AhrefsBot|SemrushBot|facebookexternalhit|HeadlessChrome).*#\1#' \
| sed -E 's#^Mozilla.*#(其他:瀏覽器 UA)#' \
| sort | uniq -c | sort -rn
示範 log 輸出：
569 (其他:瀏覽器 UA)
209 GPTBot
148 ClaudeBot
118 meta-externalagent
117 Googlebot
102 OAI-SearchBot
78 AhrefsBot
71 bingbot
58 HeadlessChrome
51 SemrushBot
49 PerplexityBot
48 CCBot
37 ChatGPT-User
29 facebookexternalhit
這份名單就是明天的重頭戲。今天你只要意識到一件事：這 1,115 列，幾乎沒有任何一筆會出現在你的 GA4 裡。 它們過不了跑 JS 那關，僥倖過了也會被 IAB 名單暗殺掉。
# 只算頁面請求(粗略:無副檔名或 .html,且回 200)
awk -F'"' '$0 ~ / 200 / {print $2, $6}' access.log \
| awk '$2 !~ /\.(css|js|png|jpg|jpeg|gif|svg|woff2?|ico|map)$/' \
| wc -l
拿這個數字，去跟同一段期間 GA4 的瀏覽量（不是工作階段）比對。這才是單位一致的決鬥。這兩者的差額，就是你網站目前的真實落差。
上面是我編的，現在來看真實數據。一個台灣的在地資訊站，某一週（2026-08-17 到 08-23）伺服器端量到的自動化請求高達 595,232 筆。
這將近 60 萬筆請求，在 GA4 裡就像沒發生過一樣。
一開始，這 60 萬筆被整包叫作「AI 請求」。但站長自己扒開 server log 後發現根本不是這麼回事：
| 筆數 | |
|---|---|
| 真正的 AI 爬蟲 | 25,336 |
| 其他自動化流量 | 569,896 |
| 合計 | 595,232 |
那 56.9 萬筆「其他」是什麼？是 SEO 工具、搜尋引擎索引、社群預覽爬蟲，還有一大坨 HeadlessChrome（259,459 筆）——那是 Chrome 無視窗模式自報的字串，任何人寫腳本都會送這個，它根本不代表任何身份。
更諷刺的是，這其中真正屬於「有真人此刻正在問 AI、AI 因此來讀這一頁」的請求，只有 2,119 筆。
同一份流量，你可以讀成 595,232，也可以讀成 2,119，中間差了 280 倍。這就是我想在第一天講破的現實：「有多少訪客不是人」這個問題，答案從來不是單一數字，而是一組數字。 而 GA4 給你的，是把這整組數字都抹掉之後的幻覺。
GPTBot。今天的指令是建立在「它說什麼就是什麼」的假設上，這只是入門量法，不是絕對真相。怎麼扒下它們的面具，是第四天的主題。HeadlessChrome 當 AI： 它是工具名稱，不是操作者。把工具名當成身分，是最容易踩進去的坑。403。只算列數不看狀態碼，你會把「被你踹出門的」當成「成功進門的」。明天我們就來拆解 log 裡那些名字：GPTBot、ClaudeBot、PerplexityBot、meta-externalagent，它們背後是誰、來幹嘛的、官方文件在哪，一次講清楚。
本文是「你的第一本 AEO x GEO 教戰手冊」系列第 1 天。系列實測與數據由 arrivl 整理 —— Growth Analytics for the Agentic Web。
iThome鐵人賽
看影片追技術